BBS Toolkit/BBS Toolkit.iso/gt_power/bgqwkb31.zip/BGQWK.TXT

Text File | 1992-06-21 | 33KB | 600 lines

[Note] only the BGQWK.EXE, BGQWK.TXT and REGISTER.FRM files are included in
       this beta packet to keep the size down to a minimum.

BGQWK 1.0 BETA 31  SUN 21 JUN 92
--------------------------------

1. About two months ago several sysops had comments ago the BGQWK.LOG file
   and the way it was handled ... I just now had the time to change the
   logging logic, so here's the breakdown on the changes I've down with it:

     the 'O' command line option: NO LOGGING AT ALL
     the 'P' command line option: PIPE ALL LOGGING TO GT.LOG in ';' format

   Now, the BGQWK.LOG (if not using the O and P options) will be keep in
   your LOGPATH directory (LO= in GT.CNF) where it should be rather than in
   the GTPATH directory as it was always keep before.  However, in some
   cases, a LOG file may end up in the GTPATH directory IF for some reason
   BGQWK is not able to make it to reading the GT.CNF file for the LOGPATH
   information.

2. Some people (many net status people who sometimes upload tons of
   messages to the door at once) wished that they could upload the packet, and
   then hangup without having to wait for BGQWK to finish unpacking.  This is
   now possible.  BGQWK will no longer monitor the carrier during a REP upload
   and will not begin again until the main menu pops up after all the messages
   have been posted.  This means that long distance net status people or heavy
   users of the door will not have to wait forever and a day when they upload
   the gigantic packets.  PLEASE NOTE that if you some other type of carrier
   monitor functioning as well, it may kick BGQWK out though!

3. A strange bug was causing the express dupe scan to be bypassed when used
   at the same time as a net status conference.  Fixed.

4. A few people told me that BGQWK was having a little trouble closing some
   message text files after people uploaded messages.  I have attempted to fix
   this problem (let me know if the file is closed now, guys).

BGQWK 1.0 BETA 30  SUN 31 MAY 92
--------------------------------

1. Since there are many different modem speeds out there, it was always
   difficult to decide on how many messages per area and total per packet to
   give to let each user download.  Now, BGQWK will help you with this
   problem.  BGQWK will now default the maximum messages per area to 100 (can
   be configured by MA=) and the maximum messages per packet to 2000 (can be
   configured by MP= in BGQWK.CNF).  HOWEVER, 2400 bps will now be used as the
   BASE, that is, if you call in at 9600 bps, (9600/2400=4), the user will be
   able to download 400 messages per area.  At 14400 bps, 600 messages, and at
   1200 bps only 50 messages per area.  (Just for your info, LOCAL rate will
   be set up as 14400).

2. Attempted to fix a small bug causing BGQWK to display "Invalid reference
   number" on many incoming messages.

3. When a net status user is uploading messages, rather than displaying all
   the message headers as they are uploaded, a brief version of the header
   will be displayed.

4. On registered BGQWKs, if a net status person is uploading messages, the
   "BGQWK 1.0ß30 ...etc" tag will NOT be appended to incoming net status
   messages regardless of the 'z' command line option.

5. A new command line option now exists for sysops with a different tastes.
   The 'c' parameter will now flip/flop the option of including the NEWS
   file in a users packet.  Okay, yes, this is confusing, so here is an
   example:

   WITHOUT 'C' OPTION:  users can choose to ALWAYS view newsfile or WHEN
        UPDATED view newsfile
   WITH 'C' OPTION:  users can choose to NEVER view newsfile of WHEN
        UPDATED view newsfile

BGQWK 1.0 BETA 29  SUN  3 MAY 92
--------------------------------

1. ATTENTION: BEFORE USING THIS BETA ---> run SYSOP.EXE and execute
   instruction number 12 (clean up USER_MSG.IDX file).  This will take
   anywhere from 2 minutes to an hour depending upon how fast your computer
   is and how many conferences you carry.  Why?  Well, it always seemed
   strange to be how BGQWK always found so many "user_msg.idx mix-matches"
   so I decided to do some investigating.  Actually, I've spent the last
   two weeks investigating this, and it seems that BGQWK was the culprit
   all along!  When BGQWK joined and unjoined users from a conference,
   certain things in the index file that were supposed to be updated were
   not, pretty much corrupting many of the index files on the system.  I've
   tried to fix all the bugs and now, if a mix-match is found, BGQWK will
   fatal out rather than attempting to "fix" the error, since fixing it was
   pretty much making things more of a mess.  This bug has existed pretty
   much since when the J)oin command off the S)elect menu was established.

2. Well, I have attempted, once again, to fix the problem with CTS
   handshaking in BGQWK.  Several of you reported that BGQWK starts sending
   garbage out to the comport.  Russell and I have attepted to test it, and
   this is what we have been able to duplicate: In Beta 28, we can force BGQWK
   to give us garbage.  In Beta 29, we can't.  I would appreicate the sysops
   and users that originally reported these garbage problems to try testing
   this with Beta 29 to see if the garbage problem went away for them to or if
   its still there.

3. A few users and sysops have reported that the duplicate scan is VERY
   slow.  Well, to help solve the problem, a new command line option is
   available, 'X', for EXPRESS DUPLICATE SCAN.  Basically, what this will do,
   if active, is this...  If a user uploads 10 messages, BGQWK will go ahead
   and perform a duplicate check on the first message.  If it passes, BGQWK
   will go ahead and assume all remaining messages will pass as well.  If the
   first messages does not pass the duplicate scan, all remaining messages
   will go through the duplicate scan until a message that is not a duplicate
   is found.  At that time, then, the express scan will continue as normal.
   Again, using the express scan is completly optional.  I hope this will help
   anybody who wants to speed up message importing a little.

4. Before posting a reference number to a message, BGQWK will first insure
   that the messages in that conference have a message that posseses the
   message number on the reference number.  (Could you follow that? :)

5. A new command line option, 'Z', will allow registered users to PREVENT
   the displaying of their registered tagline.  This was done to allow
   BGQWK to function better with BGNET, but you don't really have to worry
   about it.  Another change to allow better BGQWK/BGNET communication has
   also been done, but its not really worth mentioning as most of you won't
   even see any difference in the operation.

There are still many things waiting on the wishlist ... don't worry if
you're idea hasn't popped up yet.  I'm putting them in order of easiness
implement and most importance.

PLEASE RUN SYSOP.EXE AND EXECUTE INSTRUCTION 12 (CLEAN UP USER_MSG.IDX FILE)
BEFORE USING THIS BETA.  THIS IS IMPORTANT!!!

BGQWK 1.0 BETA 28  SAT 11 APR 92
--------------------------------

1. NEW FEATURE: A few users of the door have requested that there be a way
   to allow the users to download files by "tagging" them offline.  Well, it's
   a little different, but it can be done.  All the user has to do is enter a
   message to QMAIL or BGQWK in any conference with the subject of
   "DL:filename.ext" with no spaces.  No wildcards will be accepted.  This
   feature will work only with systems that possess a FILES.CTL files database
   (GT 17.00 only).  If you are not running GT 17.00, you _must_ specify the
   "L" command line option (no leeching).  If a user uploads a REP packet with
   a file request, BGQWK will add the file information to the GT_TAG.LST file
   (which BGQWK reads when the user begins a D)ownload command to see if any
   tagged files are waiting).  If the user Q)uits back to GT before
   D)ownloading a QWK packet, the added file will show up in GT's (ET) command
   and will be in the batch download queue.  Example message header:

      From: B.J. Guillot
        To: BGQWK
   Subject: DL:ARJ230.EXE

   dummy message
   ---
    ■ OLX 2.1 TD - BGQWK is slick

2. Two of you requested that if a command start "RZ" that BGQWK
   automatically switch into U)pload mode.  Done.  If any letter other than
   "Z" is followed by the "R", the R)eset command will be activated just as it
   always has.

3. Another BBBBB has been fixed.  Several of you said that ARJ must be given
   the "-e" switch (exclude pathnames) so some readers can function with it.
   This is now what's done.  Also, when BGQWK unARJ'es an ARJ'ed REP packet,
   the "e" parameter is used to unpack it rather than the "x" parameter.
   (This resulted in ARJ waiting for a sysop response to create a directory
   on the system rather than unpacking it in the BGQWK work directory).

4. When a user uploads a packet, BGQWK will check the signiture on the REP
   packet to determine if it was created with PKZIP or ARJ and execute the
   cooresponding unarcing program.  (Note that the sysop must have ARJ.EXE on
   his system if he/she wishes for ARJ packets to be unpacked correctly).
   Before, BGQWK would execute ARJ or PKUNZIP depending upon the user's
   setting in C)onfig, however, users were not always careful in sending
   the same style packet, so this fix should correct the problem.

5. I changed the new file scan logic somewhat.  Last time I changed it I
   really fouled it up (although it didn't show except in very rare cases).
   The new file scan should not lock anyones system up anymore if the new file
   scan is disabled.  (Also, if you disable the new file scan and don't keep a
   FILES.BBS in any directory, the error message should be longer come up).

6. Major fixes in the netmail messaging logic.  The "FR" and "RC" GT authority
   cards are now acknowledged inside BGQWK.  If a user has "FR" authorities,
   they will be able to issue netmail "dot" commands (this is also true if the
   user has "SY" authority).  A new BGQWK.CNF option ... NT= ... to represent
   your netmail net.  For example, if you are a member of net 004, set NT=4.
   This option will be used when sending netmail to systems in the local net
   so it won't charge users for it unless the "RC" authority is given to the
   user.  I've spent several hours trying to ellinate all bugs in the logic,
   but that doesn't mean I overlooked something.  I tried testing all possible
   permutations of "RC" and nets and it seems to be working.  A new field when
   uploading messages, "Cost:" will appear on the "Net/Node:" line and will
   display either "no charge" or "1 credit" depending on the situation.

7. Fixed bug causing BGQWK to exit with a runtime error if a .MES file did
   not exist on a non-GT 15 system.

8. It has been suggested that there be a way to disable the feature that
   was added a few betas ago that shows the WELCOME.BBS|CBS file when a user
   joins an new area.  The command line option to do this is "W".

BGQWK 1.0 BETA 27  TUE 24 MAR 92
--------------------------------

I apologize for releasing this beta so soon after the last one, but I
wanted to get a few BBBBBs out of the way.

1. Several of you found a BBBBB (big-bad-bgqwk-beta-bug) in the last beta.
   When I changed the BGQWK.$$$ file to have normal attributes, I forgot
   that PKZIP (or ARJ) would bag up all files in the BG$WORK$.pid
   directory.  Now, the BGQWK.$$$ file has been renamed to BG$SWAP$.pid
   which will be off the root directory of the work drive not inside of the
   work directory as it has been in previous betas.  This BBBBB only
   affected sysops using disk swapping rather than EMS swapping.

2. Fixed bug with D)etails screen when GTMDIR.BBS pathnames were had
   lowercase characters in them.

3. If a .MSG file was not found on a GT 15.50 system, BGQWK would bomb out
   with a Runtime Error.  Fixed.

4. Some cosmetic changes:  [ENTER] now shown instead of A)ll command on
   S)elect menu, format of D)etails screen shifted somewhat.

BGQWK 1.0 BETA 26  SAT 21 MAR 92
--------------------------------

1. At the request of the users of the door, I have changed the logic of
   'attended' download (not unattended) somewhat.  Before, BGQWK would create
   a QWK packet (sometimes taking several minutes) and then ask the user if
   he/she wishes to download, hangup after the download or abort the transfer
   right then and there.  Now, BGQWK will still ask this same question, but if
   a response is not given in a certain number of seconds, BGQWK will
   automatically assume "regular continue download" and will start the
   download and return to the BGQWK menu when done.  Hmm...  Now that I think
   about it though, there isn't much difference in unattended download and
   attended download now--except for the fact that unattended download will
   log off after 30 seconds or so and attended download will return to the
   prompt (timeout within 4 minutes if no keyboard input received).

2. A new option on the C)onfig menu--(O) Allows you to select how many
   seconds before a timeout occurs on the timed-prompts.  It will default to
   15, but users can set it anywhere from 5 seconds to 90 seconds.  The two
   timed prompts so far include 1) the one mentioned up above and 2) the
   automatic hangup.

3. If you wish to grant PREPACK users (/pu or /pd) sysop authorities for
   some reason, simply place a "*" right before the users first name on the
   command line.  This will allow them to send "dot" commands and receive
   private messages.  Examples:

       bgqwk . f: /pu:*russell kroll
          this will allow Russell to upload "dot" commands in prepack mode
       bgqwk . f: /pd:russell kroll
          no "*", so it only packs up regular messages
       bgqwk . f: /pd:*russell kroll
          grants sysop authority and he can prepack any private messages

4. BGQWK will now create a USER_MSG.IDX file if not found and will continue
   to create a USER_MSG.CTL file if that isn't there either.  (503+1 records
   are created in USER_MSG.IDX).

5. Fixed a minor bug in the ansi driver.  If you saved your GOODBYE screen
   with a maximum length of 255 characters, BGQWK would not add the carriage
   return, line feed correctly.  This is probably the reason several of you
   reported problems with the driver.  If you were not saving your screens
   with a length of 255 and are still having problems, PLEASE let me know.

6. Added a few things to the BGQWK.LOG.

7. Fixed a minor problem with "/pd" prepack download mode.

8. Fixed a problem with the S)elect then D)etails command misprinting
   conference extended descriptions when double-decker color commands were
   used in GTMDIR.BBS (such as $[Hello]), etc.

9. Fixed a problem with the netmail packing logic.  If a user had netstatus
   and uploaded messages into the netmail conference, more than likely, that
   same message would be echoed back to the user later.  Now, this problem
   should be taken care of.  Maybe I can have reliable netmail connects from
   now on??

10. Fixed some problems with the ^F file insertion.  BGQWK was only doing
    it with bulletins, but now it will also insert ^F files on WELCOME, NEWS,
    and GOODBYE files.

11. Dan Mancuso said that BGQWK is leaving its temporary disk file (a
    hidden file known as BGQWK.$$$) in the work directory after the user exits
    the door.  I could not duplicate the problem on my system, but I assume it
    has something to do with his Novell setup not wanting to let BGQWK delete
    the hidden file.  Well, I managed to change the swap unit so that the
    BGQWK.$$$ file is a normal attribute file so it should be deleted as the
    user exists the door.  Let me know what happens, Dan!  (By the way, if you
    do a shell, alt-1, in BGQWK, don't delete the BGQWK.$$$ file in the work
    directory unless you want to loose the current BGQWK session).

BGQWK 1.0 BETA 25  MON 15 MAR 92
--------------------------------

1. Due to the negative feedback and to popular demand <grin> the 'H' (don't
   allow G)oodbye from inside of BGQWK) command line option has been
   brought back, however, it does come with a catch--it's had a face lift.
   If you specify the 'H' command line parameter, BGQWK will still give
   your user's the option to G)oodbye from the BGQWK main menu, however, it
   will not actually drop DTR so your computer will not reboot (like some
   computers do).  BGQWK will simply exit with Errorlevel 1 so that you can
   run some kind of keyboard buffer stuffer program (like KEYFAKE) that
   will automatically generate a "G" and "Y" for the equivilant of a
   G)oodbye Y)es command from inside of GT.  Of course, using the buffer
   stuffer is completely optional so you might just inform your users that
   the G)oodbye command will simply return them to the board.

2. Several people have requested something that will let users see a more
   detailed list of conferences rather than the ten character limit of the QWK
   specification.  I've given you something in this beta--I don't know if its
   exactly what you were looking for, but it's a start in that direction.  Off
   the S)elect screen, there is a new command D)etails.  When a user chooses
   `)etails, BGQWK will run through the GTMDIR.BBS file on the BBS and
   cross-index it with the BGQWK.CNF database giving your users up to a 50
   character description of each conference.  Right now, it's only to be used
   as reference, but I think it looks interesting.

3. Support for creating ARJ QWKs and receiving ARJ REP's is now included.
   The user can select whether they want ZIP or ARJ style bags from inside the
   C)onfig menu.  (Sysops must have ARJ.EXE in their DOS PATH if they wish to
   offer ARJ style bags to their callers).

4. At the request of Jerry Hook and others, whenever a user attempts to
   J)oin a conference off the S)elect menu, the cooresponding WELCOME.CBS
   or WELCOME.BBS file will be displayed and the user will be prompted for
   a enter to return to the S)elect screen.  (The use of the WELCOME.BBS
   file is optional and BGQWK will work fine without it being there!)

5. Several sysops and users found a bug when uploading REP packets with a
   large number of messages in them.  The reference number checking
   procedure was causing BGQWK to eat up too many file handles and it would
   bomb out with an fatal i/o [4] error.  I believe that problem is now
   fixed.

6. Fixed a small problem with the finding a corrupted message logic when
   bagging new messages.

7. The log file now includes which version of BGQWK (beta-wise) is used for
   the user since many people are forgetting to tell me which beta version
   they are using when reporting bugs or suggesting comments.

8. Some cosmetic changes; V)ersion command now displays corrected on
   unregistered copies of BGQWK and a little "clock" is displayed when
   initializing the door so caller's won't worry about BGQWK locking up.
   Also, all "M)ain" commands have been changed back to "Q)uit".  It just
   drove me crazy after a while.

9. BGQWK.CNF can now be placed in individual node's GTPATH's on networks.
   I forgot drive letters were sometimes reassigned <oops>.  BGQWK will
   first check for a BGQWK.CNF in the node's GTPATH.  If it can't find it,
   it will then check the LAN path directory.

BGQWK 1.0 BETA 24  SUN  1 MAR 92
--------------------------------

1. DELETE YOUR BGQWK.CTL FILE!!!  The format has changed (yet, yet, yet
   again).  I removed some unimportant fields but, at the request of many
   of you, added something internal to BGQWK that will keep your BGQWK.CTL
   file at the smallest possible size.  On my system, I probably had like
   100 people that had opened the BGQWK door, but only 20 or so ever used
   it.  With the new format control file, if a user did not do anything (no
   QWK packet downloads), there record will be there, but if a new user
   enters the door after they did, their record will be overridden so no
   space is wasted (similiar to the way GT Power handles deleted records).
   And LAN user's don't have to worry.  The new control file contains an
   "in use" byte so BGQWK won't overwrite a current user's record.  (In
   L)ist mode, any "in use" record will be highlighted if you are in ansi
   mode in the door).

2. IMPORTANT FOR SYSOPS USING BGQWK IN "PREPACK" MODE --- The command line
   parameter for prepack mode has changed to /PD:first last.  Example:

   bgqwk . f: /pd:russell kroll

   Prepack mode can now be used in reverse... to accept REP packets rather
   than create QWK packets.  To use Prepack mode in reverse, simply:

   bgqwk . f: /pu:russell kroll

3. People in my support conference had reported difficulties when first
   installing BGQWK because it wouldn't acknowledge their general message base
   was in the config file.  I played around with this but could not duplicate
   the problem with the caps, however, I did discover another problem and
   fixed that.  If the main message area was greater than 255, BGQWK will not
   recognize it.

4. Some cosemetic adjustments have been made.

5. If a user's netmail message was identified as a duplicate, a netmail
   credit would be taken from them anyway.  Fixed.

BGQWK 1.0 BETA 23  SUN 23 FEB 92
--------------------------------

There hasn't been a beta release in about a month.  I was pretty busy and
just now had the chance to work on it.  Please read the following change
information.  Especially the first three items.

1. In order to optimize BGQWK for LAN use, I made a decision that may
   have an affect on your setup.  From now on, all BGQWK support files
   (BGQWK.CTL, BGQWK.HLP, BGQWK.CNF, BGQWK.KEY) must be placed in your
   LANPATH directory (if you don't have LANPATH directory, it's the
   GTPATH directory).  If you still don't know what I'm talking about, just
   copy all the BGQWK*.* into the same directory with your USER.CTL file.
   This change is being done so that people don't have multiple copies of
   BGQWK files lying everywhere.  This change was recently done only for
   BGQWK.CTL, and it worked so well, I decided to do it for all BGQWK
   support files!

2. The 'H' (allow hangup) command line parameter has been removed.  In
   order for BGQWK to operate the same on every board and to not confuse users
   of the door, I felt this was necessary.  If your board reboots because the
   carrier is dropped, you need to get a hold of DVDOOR and install it in your
   AUTOEXEC.BAT file.

3. Many people have been complaining about "fatal error: 8 on exec("
   errors.  An "8 on exec" means that not enough memory is left to run the
   child process (DSZ, PKZIP, PKUNZIP, COMMAND.COM, etc).  A way to solve this
   problem is overlay the door, but I put something inside BGQWK to help solve
   this problem for you as well so you won't have to overlay the BGQWK door
   anymore!  This beta version, when shelling to a child process, will dump
   itself into EMS or a disk file (BGQWK.$$$) and give the child processes
   about an extra 150K of memory to work with!  I've tried it on my computer
   and on Russell's computer running Desqview and it seems to work fine on
   both so I hope it works good on yours.  Let me know how it goes!

4. Warren Leadbeatter found a security bug in BGQWK relating to netmail
   handling.  If you use to use GT's tight netmail security features, add
   the 'T' parameter to the BGQWK command line.  If you don't know what I'm
   talking about, you can ignore this option.  Since I don't have a "real"
   netmail

5. Eric McDerrmott discovered a gigantic bug with the processing of the PTR
   file.  What did it do?  Well, basically, it would mess up all your last
   read pointers rather than fixing them, <grin>.  Fixed.

6. Craig Clark discovered ^F<filename> substitutions in bulletins were not
   working.  I added the capability for one-deep subs.  I didn't really feel
   it was that necessarily to go more than one-deep.  Let me know.

7. Bryan Nylin discovered a GT-related bug that caused problems with some
   offline mail readers.  Since GT stores 0:00 as 24:00, the mail readers
   thought the time was corrupt and refused to display it.  BGQWK now changes
   the "24:xx" time to " 0:xx" when inserting in the QWK packet.

8. More cosmetic changes.  At the request of some people, I've changed many
   of the Q)uit commands to M)enu so users won't get confused.  Personally,
   I don't like it too well and might change it back to Q)uit if I get many
   negative responses.

BGQWK 1.0 BETA 22  SAT 25 JAN 92
--------------------------------

1. Changed REP packet processing logic drastically.
   a) All messages sent to the door will be marked NOT RCV'D regardless of
      the flag in the MESSAGES.DAT file
   b) If a message is directed to "SYSOP" normally BGQWK converts it to the
      sysop's name, however, now, if BGQWK senses the message is directed to a
      remote system, BGQWK will leave the "SYSOP" name intact as "Sysop".  (A
      remote system is detected if the message is directed to someone via
      netmail or if the first two characters in the message are "->".
   c) BGQWK will no longer use the date/time stamp when checking for
      duplicate packets since some computer platforms don't add a date/time
      stamp to their REP files causing BGQWK to think ALL uploaded messages
      were duplicates.  As a result, the R)eset..D)upe function has also
      been removed since it is meaningless now.
   d) Several people have reported lockups when users have uploaded REP
      packets.  I believe I've fixed the problem.  (It had to do with
      special control messages not being handled correctly).
   e) Messages uploaded will now maintain their ORIGINAL date and time, as
      entered by the user.  Why?  Because several people have told me that
      duplicate killers are killing uploaded messages because the date and
      time are the same (because fast computers can unpack, say, 10
      messages in the same time-minute-frame, but people usually don't
      enter messages in the same time-minute-frame).
   f) as messages are uploaded, BGQWK will scan for duplicates in the
      message base before posting the message.  This may take a little longer,
      but it's probably worth it.
   g) when messages are uploaded from a NON-net status person, if the
      current user name does not match the uploaded message user name, the
      message will not be posted at all--before the message would be inserted
      into the base with the current user's name rather than the message.dat
      user name

2. Daniel Liebling discovered if a user did a C)onfig..T)ransfer Protocol
   and then hit ENTER, their current protocol would become blank.  Fixed.

3. Allow users to [H]angup after or [ESC] abort transfer before transfer
   begins at the request of several people.

BGQWK 1.0 BETA 21  SAT 18 JAN 92
--------------------------------

1. Fixed a MAJOR problem with the net status logic.  Net status would never
   work properly on conferences 0, 128, 256, etc, and on all the rest, the
   positions were shifted over one causing much trouble.  Thanks to Richard
   Walker for discovering this bug.

2. The P)revious command off the S)elect meny now works properly when in
   the first screen.

3. Fixed some problems with linking message reply numbers.  When a
   reference number was used, the "see reply" flag was being used instead of
   the "see original".  Fixed that and now also flag the other message header
   so that a reference pointer is generated.  This is probably a bug that goes
   all the way back to the BGPCK days.  Fixed.

4. Jerry Hook and others discovered that if you specified a file to be
   inserted as a new file list (via the UP= directive), it wouldn't be
   inserted.  This feature is now BACK!  (Remember, this is completely
   optional).

5. Fixed a rather peculiar problem with the index/hashing logic.  I have
   two users on my board "Clif Davis" and "Greg Miller".  Because their hash
   codes just happen to be the same, BGQWK would assume "Clif Davis" was on
   the board when, in actuality, it was "Greg Miller".  (Yes, that may have
   caused some potential security problems).  All is fixed now, I believe.

6. Fixed a few minor problems with the ansi driver (that's why ASCII
   screens were having double linefeeds, etc and also the <ESC>[xH commands
   were not being treated properly.  Fixed another bug in the ansi driver
   that caused background attributes to be brough up rather than blinking
   attributes.  Fixed a bug that caused BGQWK to lock up if an illegal ansi
   call was read.

BGQWK 1.0 BETA 20  SAT 11 JAN 92
--------------------------------

ATTENTION ALL REGISTERED USERS: Chris Cook discovered quite a big bug in
the registration logic that causes all registered BGQWK's beyond serial
number 29 to assume they are unregistered.  This problem has been
corrected, BUT in order to do so, I had to change the format of the
BGQWK.KEY file.  You will need to pick up a new KEY file in door number 4!

We've overshot the tentative release date a month already, so we might as
well keep beta testing, <grin>.

Several bugs have been reported, but I just didn't have the time to get all
of them.  I have corrected as many as I could for this beta.

This release will only contain the regular version of BGQWK.EXE.  From my
experience, the AT version ran about the same speed as the XT version.  Do
any of you have any comments about the difference in XT and AT versions?

Well, the source code to BGQWK has gotten so large that I can't even use
the Turbo Pascal 5.5 internal editor anymore, so all future versions will
be compiled under Turbo Pascal 6.0.  (I'll just use it's command line
processor since I _hate_ the 6.0 environment!)

Beta 19 was very buggy.  Numerous bugs have been fixed in this release.

1. The problem John Ferra's users have been reported has finally been
   corrected (the problem with private messages sent through Winqwk were being
   marked <RCV'D> before it actually was).

2. I have again tried to fix the problem with the garbled select screens on
   some systems running high speed modems and I belive I fixed it.  Let me
   know please!

3. A bug since long betas since has been fixed.  If a user dropped carrier
   on the board, BGQWK would not clean up its work directory.  Fixed.

4. Finally!  Errors will now be logged in the BGQWK.LOG file that is
   created in the GTPATH directory.  The log file will probably be changing
   all the time to suit the needs of the sysops running the door.  Let me know
   what all you want me to add to the log file.

5. Dan Mancuso has suggsted that BGQWK not bomb out when it encounters a
   missing .MSG or .MES file.  This is now done and BGQWK will report the
   error on screen and in the log file.

 1-10-92 19:27 Guest Account~Houston, Texas
 1-10-92 19:28 CORRUPTED [D:\MAIL\GENERAL\GTMSGS\00100.MES] SOM2
 1-10-92 19:28 CORRUPTED [D:\MAIL\GENERAL\GTMSGS\00100.MES] SOM4
 1-10-92 19:28 CORRUPTED [D:\MAIL\GENERAL\GTMSGS\00100.MES] SOM7
 1-10-92 19:28 user returns to the board

   If you are using GT 16 or later, the SOM id will also be given for
   debugging purposes.

6. Jerry Deguzman reported a bug that has now been fixed.  BGQWK was not
   "trimming" imbedded spaces from the end of some strings in the BGQWK.CNF
   file causing problems with PKZIP.

7. Fixed some little strang things with the strip bit routines.  If BGQWK
   displays a "unregistered" tagline, high bit characters were not being
   stripped.  Fixed.  Also, when the bits are stripped, if it happens to come
   out to be an ^X, ^Z or null, they will be converted to "~".  (Those some
   redifintions will be used on normal conferences as well).  Also, in strip
   bit conferences, any ESC character will be changed to "~" as well.

8. Several people reported a major bug in prepack mode.  If no new messages
   were available, the program would get stuck in an infinite loop.  Fixed.

---------------truncated to save space